Context-dependent message management

ABSTRACT

A method, executed by a computer, for context-dependent message management, includes receiving proxy recipient information from a target recipient, detecting that a message is being drafted to the target recipient while the target recipient is unavailable, and suggesting a proxy recipient in place of the target recipient. The proxy recipient information may identify multiple proxy recipients organized according to message topic. The proxy recipient information may also describe one or more topics for which a target recipient is available and/or suitable. Proxy recipient information may be determined automatically or may be provided by a user. Furthermore, the proxy recipient information may include availability information. In one embodiment, a user approves of the proxy recipient prior to transmitting the message. In another embodiment, the target recipient is able to preemptively receive the message. A computer system and computer program product corresponding to the above method are also disclosed herein.

BACKGROUND OF THE INVENTION

The present invention relates generally to messaging, and morespecifically to the field of message management in the case of absentrecipients.

When a sender sends a message to an absent recipient, that message maygo unread until the recipient becomes available again. Any delay inaddressing a message may be undesirable, especially in cases where themessage is urgent or a rapid reply to the message is sought.

SUMMARY

As disclosed herein, a method, executed by a computer, forcontext-dependent message management includes receiving proxy recipientinformation from a target recipient, detecting that a message is beingdrafted to the target recipient while the target recipient isunavailable, and suggesting a proxy recipient in place of the targetrecipient. The proxy recipient information may identify multiple proxyrecipients organized according to message topic. The proxy recipientinformation may also describe one or more topics for which a targetrecipient is available and/or suitable. Proxy recipient information maybe determined automatically or may be provided by a user. Furthermore,the proxy recipient information may include availability information. Inone embodiment, a user approves of the proxy recipient prior totransmitting the message. In some embodiments, the target recipient isable to preemptively receive the message. A computer system and computerprogram product corresponding to the above method are also disclosedherein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart of one embodiment of a method for messaging proxyrecipients in accordance with the present invention;

FIG. 2 is a flowchart of one embodiment of a method for enumeratingout-of-the-office events in accordance with the present invention;

FIG. 3 is a flowchart of one embodiment of a method for determiningtopics in accordance with the present invention;

FIG. 4 is a user interface diagram depicting one example of an proxyrecipient information interface in accordance with the presentinvention;

FIG. 5 is a user interface diagram depicting one example of a topicindex interface in accordance with the present invention; and

FIG. 6 is a block diagram depicting one example of a computing apparatus(i.e., computer) suitable for executing the methods disclosed herein.

DETAILED DESCRIPTION

Embodiments of the present invention relate generally tocontext-dependent message management, and more specifically, tomessaging when an originally intended recipient of the message, known asa “target recipient,” is unavailable. In one embodiment, theunavailability of a target recipient may be overcome by suggesting anappropriate back-up, or “proxy” recipient. The proxy recipient may beselected on the basis of the subject matter or topic of the message. Thetypes of messages may include e-mail, short message service (SMS),multimedia messaging service (MMS), or any other suitable messaging.

It should be noted that references throughout this specification tofeatures, advantages, or similar language herein do not imply that allof the features and advantages that may be realized with the embodimentsdisclosed herein should be, or are in, any single embodiment of theinvention. Rather, language referring to the features and advantages isunderstood to mean that a specific feature, advantage, or characteristicdescribed in connection with an embodiment is included in at least oneembodiment of the present invention. Thus, discussion of the features,advantages, and similar language throughout this specification may, butdoes not necessarily, refer to the same embodiment.

Furthermore, the described features, advantages, and characteristics ofthe invention may be combined in any suitable manner in one or moreembodiments. One skilled in the relevant art will recognize that theinvention may be practiced without one or more of the specific featuresor advantages of a particular embodiment. In other instances, additionalfeatures and advantages may be recognized in certain embodiments thatmay not be present in all embodiments of the invention.

These features and advantages will become more fully apparent from thefollowing drawings, description and appended claims, or may be learnedby the practice of the invention as set forth hereinafter.

The present invention will now be described in detail with reference tothe Figures. FIG. 1 is a flowchart of one embodiment of acomputer-implemented messaging method 100 in accordance with the presentinvention. As depicted, the messaging method 100 includes receiving(110) proxy recipient information for a target recipient, detecting(120) a message being drafted to a target recipient, determiningavailability (130) of the target, suggesting (140) an proxy recipientfor the target recipient, and determining if there is another target(150). The messaging method 100 thus enables a sender to deliver amessage to a proxy recipient in lieu of an absent target recipient,which may tend to decrease the amount of time that a message goesunread.

Receiving (110) proxy recipient information for a target recipient mayinclude collecting details from a target recipient's messaging client.The messaging client may be an e-mail client, webpage executing in abrowser, smartphone texting app, or the like. In one embodiment, thisact of collection is mediated by a software component, such as aplug-in, add-on, or extension, which is associated with the messagingclient. In some embodiments, collection may be performed by a separateprogram or device external to the messaging client. On a mobileplatform, the proxy recipient information may be collected by an appthat is installed on a mobile device.

The details that are collected from a target recipient are collectivelyreferred to herein as “proxy recipient information.” In one embodiment,the proxy recipient information is a list of proxy recipientscorresponding to message topics. For example, if a topic of a message isadvertising, the proxy recipient information may provide a proxyrecipient who is employed in a marketing position. In some embodiments,the proxy recipient information includes the schedules or currentavailability of proxy recipients. The relationship between proxyrecipients and message topics may be determined by a user or determinedautomatically by analyzing prior message history. In one embodiment,this relationship is determined by applying machine learning techniques,such as data-mining, to the message and/or message history.

Detecting (120) a message being drafted to a target recipient mayinclude monitoring any recipient fields in the user interface of a draftmessage. For example, while drafting an SMS or MMS message, the userinterface may contain a “to:” field, whereas an email client may contain“to:”, “cc:” and/or “bcc:” fields. In some embodiments, whenever atarget recipient's contact information is entered into any sort ofrecipient field, detection 120 occurs.

Determining availability (130) of the target may include a variety ofapproaches. For example, availability may be determined by checking theonline status, network presence, and/or schedule of a target recipientfor availability. In some embodiments, a target recipient's schedule isobtained from stored schedule data, such as a calendar or plannerdatabase, in which the target recipient's schedule was entered. Thetarget's availability may be determined from the target's schedule orfrom a group schedule. For example, an office schedule that lists allmembers of XYZ Committee as unavailable on Tuesdays may allow for thedetermination that a target is unavailable given that the target is amember of XYZ Committee. “Availability” of a target may mean that thetarget is in a situation or location where the target is unable (or doesnot wish) to respond to messages. In some embodiments, a target isunavailable if the target is out of the office. If the result of thetarget availability decision step 130 is that a target is not available,the proxy recipient messaging method 100 proceeds to the step ofsuggesting (140) a proxy recipient; otherwise, the proxy recipientmessaging method 100 terminates.

In some embodiments, the target's availability is a function ofparticular actions or inactions relating to the target's messagingdevice(s). If the messaging device is a computer, such as a laptop ordesktop, availability may be determined by monitoring mouse movements,keyboard strokes, network activity or connectivity, hard drive activity,and/or power state. On the other hand, if the messaging device is amobile device, availability may be determined by monitoring storageactivity, lock screen status, network activity or connectivity,geographical location, power state, acceleration, velocity, and/or tiltor orientation status. For example, a target may be deemed “unavailable”if the target's messaging device is off or physically out of the office,the messaging device has been physically undisturbed for a period oftime, or the messaging device is near the target's home. A target mayalso set his or her availability status by enabling or disabling asetting of a software component on the messaging device.

Suggesting (140) a proxy recipient for the target recipient may includeproviding a proxy recipient in lieu of the unavailable target recipient.In one embodiment, this replacement is performed automatically. The actof replacement may be reflected in the recipient field of the draftmessage; for example, “proxy recipient A” may appear in place of or inany locations of the user interface where “target recipient T” hadpreviously been entered. In some embodiments, the proxy recipient who issuggested has been verified to be presently available. The proxyrecipient may also be expected to be available before the targetrecipient is scheduled to be available.

In one embodiment, each proxy recipient that is suggested must beapproved by the sender. The approval process may involve a useraccepting the substitution of recipients. If a sender does not approveof the substitution, the message may be sent to the target recipient. Insome embodiments, multiple proxy recipients are provided for eachunavailable target recipient, and the sender chooses to send the messageto the target recipient, one proxy recipient, a combination of multipleproxy recipients, or a combination of one or more proxy recipients aswell as the target recipient.

Determining (150) if there is another target may include checking foradditional target recipients of the message. If there are no more targetrecipients, the computer implemented proxy recipient messaging method100 ends. If there is one or more additional target recipients, theproxy recipient messaging method 100 returns to the target availabilitydetermination operation 130. In this manner, there may be an opportunityfor each target recipient to be checked for availability and replacedwith a proxy recipient.

In some embodiments, the target recipient is notified that, while he wasunavailable, a message originally intended for him was sent to a proxyrecipient. The target recipient may choose to read the message. In oneembodiment, if the target recipient elects to read the message beforethe proxy recipient has read the message, the target recipient maychoose to retake ownership of the message, at which point the message isdelivered to the target recipient. When a target recipient retakesownership of a message, the message may also be removed from the proxyrecipient's inbox, as there may no longer be a need for a proxyrecipient.

FIG. 2 is a flowchart of one embodiment of an out of the office (OOTO)event enumeration method 200 in accordance with the present invention.As depicted, the OOTO event enumeration method 200 includes collectingand verifying (210) contact information, collecting (220) proxyrecipient information, and determining (230) OOTO events. In oneembodiment, an OOTO event occurs whenever a recipient is unavailable,does not wish to be disturbed, or is otherwise unable to respond tomessages.

Collecting and verifying (210) contact information may include gatheringinformation such as a user's contact address. A user's contact addressmay include an email address, phone number, username, or the like. Insome embodiments, the contact information is inputted by a user; inother embodiments, another individual may input a user's contactinformation on behalf of that contact. During its collection, thecontact information may be verified by the individual inputting thecontact information.

Collecting (220) proxy recipient information may include gathering froma sender information regarding the sender's proxy recipients for variousmessage topics. In order to suggest an appropriate proxy recipient forthe target recipient, the topic(s) of the message must be determined andcorrelated to a proxy recipient; the proxy recipient informationprovides a database to accomplish this correlation. The proxy recipientinformation may be collected by way of a target inputting one or moreproxy recipient for each message topic; for example, a mathematician maylist a peer as a proxy recipient for messages relating to the topic ofcalculus. Thus, a sender is still able to pose a calculus homeworkquestion to an individual (here, the peer) despite the unavailability ofthe target recipient. Proxy recipient information may also include theschedules of proxy recipients and/or the target recipient.

Determining (230) OOTO events may include analyzing the proxy recipientinformation and determining which target recipients and/or proxyrecipients are out of the office at a given time. By enumerating all ofthe OOTO events, a sender may ensure that a message reaches an availablerecipient, and is not sent to a recipient who is unavailable, e.g. whosestatus is OOTO. In one embodiment, a target recipient has multiple proxyrecipients listed in his proxy recipient information for a given topicsuch that the unavailability of the target and one of the target's proxyrecipients does not prevent the message from being delivered to a third,available proxy recipient. OOTO events may be determined by analyzingcalendar databases or determining that a user is unavailable asdisclosed herein.

FIG. 3 is a flowchart of a computer-implemented topic determinationmethod 300 in accordance with the subject invention. As depicted, thetopic determination method 300 includes receiving (310) keywords from atopic index, searching (320) a message for keywords, and determining(330) the topic of a message. The topic determination method 300ascertains one or more topics of a message, thus ensuring that any proxyrecipients who are suggested are appropriate, given the subject area ofthe message.

Receiving (310) keywords from a topic index may include accessing atopic index in order to obtain a list of keywords. In some embodiments,the topic index that is accessed is a sender's own topic index; in otherembodiments, topic indices belonging to one or more proxy recipients areaccessed. In some embodiments, there is a public topic index that isaccessible by all users and contains a global list of topics andkeywords for all users. In certain embodiments, each user has a localcopy of a global list of topics and keywords for all of the other users.Thus, the list of topics may be generated from a topic index that islocal to the sender's messaging device, remote, or a combinationthereof.

Searching (320) a message for keywords may include scanning a sender'smessage for the presence of the keywords obtained by the keywordreceiving module 310. The body of the message may be searched, or themessage title, or both.

Determining (330) the topic of a message may include assigning a topicto the message based on the presence of the keywords found in themessage. In some embodiments, each keyword results in the assignment ofa topic to the message; thus, a message with multiple keywords may spanmultiple topics in subject area. Statistical analysis of the presence ofkeywords may determine a ranked list of topics. For example, if amessage mentions the keyword “TPS report” seven times, “dinner” threetimes, and “meeting” twice, the message topic determination module 330may determine that the message's main topic is a TPS report, itssecondary topic is dinner, and its tertiary topic is a meeting. Othertechniques to analyze the content of a message by keywords, or the like,are well-known in the art and are likewise suitable to employ herein.

FIG. 4 is a user interface diagram depicting one example of proxyrecipient information 400 in accordance with the present invention,including a list of topics 410 and corresponding proxy recipients 420,as well as the proxy recipients' availability 430 and schedule 440. Theproxy recipient information 400 enables a user to access and edit theproxy recipient information as well as to provide additionalinformation.

The proxy recipient information 400 is organized by topics 410 andcorresponding proxy recipients 420. In one embodiment, there is oneproxy recipient 420 per topic 410. In some embodiments, multiple proxyrecipients may be provided for each topic 410. The topics 410 mayinclude any subject of a message. As depicted, the topics 410 all relateto business departments; however, topics 410 are not limited to thebusiness world, and any matter of discussion that a message mightencompass is suitable as a topic 410. The proxy recipients 420 mayinclude the one or more recipients who are assigned to a particulartopic 410. In this depiction, “Alfred” is a proxy recipient foraccounting topics, whereas “Becky” is a proxy recipient for humanresource topics. In one embodiment, the proxy recipient 420 fields aremenus that list the available proxy recipients by name, nickname, emailaddress, phone number, or the like.

Availability 430 may include the current availability status of a proxyrecipient. For example, if a proxy recipient sets her status to OOTO,she would not be listed as available. In one embodiment, a proxyrecipient's availability 430 is determined by accessing the proxyrecipient's calendar, or by other means previously disclosed herein.Availability may also be obtained by referring to a proxy recipient'sschedule 440, which provides data about each proxy recipient's past,present, and future availability.

FIG. 5 is a user interface diagram depicting one example of a topicindex 500 in accordance with the present invention, including a list oftopics 410 and corresponding keywords 510. The topic index 500 enables arecipient or sender to associate each topic 410 with one or morekeywords 510. A message may thus be determined to cover a particulartopic via the keywords contained within the message. The keywords 510may include any words that are associated with the corresponding topic410. In some embodiments, the sender or recipient may customize theirtopics and keywords by adding additional topics and/or keywords.

A particular topic 410 may be linked to a message by the presence of oneor more of its corresponding keywords 510. The presence of any of thekeywords 510 for a topic 410 may implicate that topic; for example, ifthe keyword 510 “money” appears in the message, it may be determinedthat “accounting” is a topic 410 of that message. In some embodiments, acertain minimum number or percentage of keywords must appear beforeassociating the message with that topic 410. If that is the case,“money” alone may not result in determining that “accounting” is a topic410, but “money,” combined with words like “payroll” and “budget” maymeet certain predefined word frequency criteria to implicate the topic410 of “accounting.” Similarly, messages may be ranked by topic 410depending on how many times each of their keywords 510 appear in themessage.

The foregoing methods enable context-dependent message management. FIG.6 is a block diagram depicting components of a computer 600 suitable forexecuting the methods disclosed herein. It should be appreciated thatFIG. 6 provides only an illustration of one embodiment and does notimply any limitations with regard to the environments in which differentembodiments may be implemented. Many modifications to the depictedenvironment may be made.

As depicted, the computer 600 includes communications fabric 602, whichprovides communications between computer processor(s) 604, memory 606,persistent storage 608, communications unit 612, and input/output (I/O)interface(s) 614. Communications fabric 602 can be implemented with anyarchitecture designed for passing data and/or control informationbetween processors (such as microprocessors, communications and networkprocessors, etc.), system memory, peripheral devices, and any otherhardware components within a system. For example, communications fabric602 can be implemented with one or more buses.

Memory 606 and persistent storage 608 are computer readable storagemedia. In the depicted embodiment, memory 606 includes random accessmemory (RAM) 616 and cache memory 618. In general, memory 606 caninclude any suitable volatile or non-volatile computer readable storagemedia.

One or more programs may be stored in persistent storage 608 forexecution by one or more of the respective computer processors 604 viaone or more memories of memory 606. The persistent storage 608 may be amagnetic hard disk drive, a solid state hard drive, a semiconductorstorage device, read-only memory (ROM), erasable programmable read-onlymemory (EPROM), flash memory, or any other computer readable storagemedia that is capable of storing program instructions or digitalinformation.

The media used by persistent storage 608 may also be removable. Forexample, a removable hard drive may be used for persistent storage 608.Other examples include optical and magnetic disks, thumb drives, andsmart cards that are inserted into a drive for transfer onto anothercomputer readable storage medium that is also part of persistent storage608.

Communications unit 612, in these examples, provides for communicationswith other data processing systems or devices. In these examples,communications unit 612 includes one or more network interface cards.Communications unit 612 may provide communications through the use ofeither or both physical and wireless communications links.

I/O interface(s) 614 allows for input and output of data with otherdevices that may be connected to computer 600. For example, I/Ointerface 614 may provide a connection to external devices 620 such as akeyboard, keypad, a touch screen, and/or some other suitable inputdevice. External devices 620 can also include portable computer readablestorage media such as, for example, thumb drives, portable optical ormagnetic disks, and memory cards.

Software and data used to practice embodiments of the present inventioncan be stored on such portable computer readable storage media and canbe loaded onto persistent storage 608 via I/O interface(s) 614. I/Ointerface(s) 614 may also connect to a display 622. Display 622 providesa mechanism to display data to a user and may be, for example, acomputer monitor.

The programs described herein are identified based upon the applicationfor which they are implemented in a specific embodiment of theinvention. However, it should be appreciated that any particular programnomenclature herein is used merely for convenience, and thus theinvention should not be limited to use solely in any specificapplication identified and/or implied by such nomenclature.

The embodiments disclosed herein include a system, a method, and/or acomputer program product. The computer program product may include acomputer readable storage medium (or media) having computer readableprogram instructions thereon for causing a processor to carry out themethods disclosed herein.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowcharts and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

What is claimed is: 1-8. (canceled)
 9. A computer program product formessaging, the computer program product comprising: a computer readablestorage medium and program instructions stored on the computer readablestorage medium, the program instructions comprising instructions to:receive proxy recipient information from a target recipient; detect thata message is being drafted to the target recipient while the targetrecipient is unavailable; and suggest a proxy recipient for the targetrecipient to a user.
 10. The computer program product of claim 9,wherein the proxy recipient information identifies a plurality of proxyrecipients for a corresponding plurality of topics.
 11. The computerprogram product of claim 9, wherein the proxy recipient informationspecifies one or more topics for the target recipient.
 12. The computerprogram product of claim 9, wherein the proxy recipient information isautomatically determined.
 13. The computer program product of claim 9,wherein the proxy recipient information is provided by the user.
 14. Thecomputer program product of claim 9, wherein the proxy recipientinformation comprises availability information.
 15. The computer programproduct of claim 9, further comprising instructions to enable the userto approve the proxy recipient previous to transmitting the message. 16.The computer program product of claim 9, further comprising instructionsto enable the target recipient to preemptively receive the message. 17.A computer system for messaging, the computer system comprising: one ormore computer processors; one or more computer readable storage media;program instructions stored therein for execution by at least one of theone or more computer processors, the program instructions comprisinginstructions to: receive proxy recipient information from a targetrecipient; detect that a message is being drafted to the targetrecipient while the target recipient is unavailable; and suggest a proxyrecipient for the target recipient to a user.
 18. The computer system ofclaim 17, wherein the proxy recipient information identifies a pluralityof proxy recipients for a corresponding plurality of topics.
 19. Thecomputer system of claim 17, wherein the proxy recipient informationcomprises availability information.
 20. The computer system of claim 17,further comprising instructions to enable the user to approve the proxyrecipient previous to transmitting the message.
 21. The computer systemof claim 17, wherein the proxy recipient information specifies one ormore topics for the target recipient.
 22. The computer system of claim17, wherein the proxy recipient information is automatically determined.23. The computer system of claim 17, wherein the proxy recipientinformation is provided by the user.
 24. The computer system of claim17, further comprising instructions to enable the target recipient topreemptively receive the message.